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ABSTRACT 


NPSNET-IV.7J has a limited capability to display up to 10 Dismounted Infantry (DI) 
icons due to the enormous number of rendered polygons and computational load required. 
In order to provide a more realistic training scenario for the user, NPSNET-IV.8. 1 requires 
the capability to display at least 150 independent DI entities in real-time. 

Requirements were satisfied by creating low-level and medium level-of-detail auton- 
omous and controlled DI icons and their associated motion algorithms to support existing 
DI models in NPSNET-IV.8.1. Additionally, view volume culling techniques were em- 
ployed to reduce polygon flow through the graphics pipeline and enhance system speed. 

This research enhances the capabilities of the NPSNET-IV.8.1 to be able to display 
150 DI icons.The inclusion of level of detail models composed of fewer polygons than an 
existing high level model, together with view volume culling ensure NPSNET-IV.8.1 can 
Satisfy sponsor requirements of displaying 150 DI icons and still maintain a frame rate of 


10-15 frames per second. 
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I. INTRODUCTION 


A. BACKGROUND 


The United States military is committed to the development of virtual world tech- 
nologies and distributed interactive simulation (DIS) to more effectively and economically 
train warriors of the future [HLMOHN]. Effective implementation of DIS may potentially 
remove the necessity of expensive training travel and large scale exercises. All personnel 
involved in computerized simulations will benefit from their ease of use and real-time feed 
back in training scenarios. DIS has proven itself effective in providing networked interac- 
tion between a limited number of participants across the nation. As requirements for more 
participants and more realistic activities steadily increase, DIS must be able to keep pace 
with the quickly changing needs of users. It must be able to handle the increase in users and 
the large amounts of information interchanged in the network.[HLMOHN] 

The main driving force behind large-scale virtual simulations has been the United 
States Army. Their vision to have many thousands of independent entities participating in 
simulations by the end of the century drives the need to make entities appear more realistic 
and versatile in their interaction in a virtual world. As more entities are added to a world, 
its realism is increased. Unfortunately, additional players and more realistic entity icons 
come at the expense of system speed and operational trade-offs. Inclusion of more icons 
slows down the system, thereby reducing the reality one seeks to achieve. As this is an 
undesirable effect, many speed-up techniques are implemented to reduce this while retain- 
ing system realism and user interest. The emphasis of this joint thesis is to provide one 


method of rendering to enhance system realism while not reducing overall system speed. 


B. PROBLEM 


In order to ensure the virtual battlefield is as realistic as possible, NPSNET-IV.8. 1 
designers continue to develop models for the system that replicate, as Closely as possible, 


actual features in the real world. These models include life-like trees, shrubs, highly 





detailed buildings, trucks, jets, tanks, helicopters, ships, submarines, and people. NPSNET- 
IV.8.1 is currently successful in accurately portraying most of these eniities at real-time 
rendering speeds. However, the system is limited to the number of entities it can accurately 
render at high speeds before one experiences noticeable system degradations. When 
networking the system on a worldwide scale, system degradation may be more pronounced, 
further reducing the number of entities that may participate. 

The recent inclusion of the University of Pennsylvania’s Jack Motion Library (Jack 
ML) software for rendering high resolution humans has added a new feature to NPSNET- 
IV.7J that was previously unavailable. While Jack ML has become the solution for render- 
ing high resolution humans in NPSNET-IV.8.1, the Jack ML model has proven too 
cumbersome for required large scale exercises where many foot soldiers (dismounted 
infantry or DI) are needed. The Jack ML model used in NPSNET-IV.8.1 for high resolution 
rendering is composed of 478 individual polygons [JPGRAN]. While this model is highly 
efficient for rendering DI in the foreground, such a model is not efficient for entities beyond 
high resolution perception where a lower level of detail (LOD) model could be used. The 
current implementation of Jack ML does not provide for LOD models as an entity moves 
further from one’s view frustum. As such, the 478-polygon model is rendered at all view- 
ing ranges. As a result, creation of more than 20 DI entities on NPSNET-IV.8.1 degrades 
system functionality, namely frame rate, well below acceptable requirements. Since this is 
Clearly not desired, and NPSNET-IV.8.1 sponsors require at least 150 DI entities be effi- 
ciently renderable in the near term, LOD models of the DI are required to make this possi- 


ble while allowing other entities to be rendered at the same time. 


C. FOCUS / APPROACH 
In order to address the speed and rendering requirements of NPSNET-IV.8.1, two 
techniques are employed. The first is the design and implementation of three LOD DI 


models. The second uses view frustum culling to save rendering time. 





1. LOD Models 
With the sponsor required increase of DI entities, current NPSNET-IV.8.1 Jack ML 


models are augmented with three more distinct level of detail models. These LOD models 
are provided to the NPSNET-IV.8.1 system software and are automatically loaded based 
on user view point range from a displayed DI entity. Using the capabilities designed into 
IRIS Performer Application Programming Interface (API) software, LOD models are load- 
ed as needed using the pfLOD command. The features provided by the software allow users 
to define specific level of detail models and ranges for rendered entities. A key aspect of 
the LOD models designed for DI entities is that they have significantly fewer individual 
polygons and articulated joints per model. This large reduction in polygon count and artic- 


ulations reduces overall system degradation and allows the creation of the 150 DI entities 


required. 


2. View Volume Culling 

In order to preserve frame rendering rates where DI entities are involved, view 
volume culling is implemented to reduce system overhead for field of view rendering. This 
technique utilizes one’s field of view in the view frustum to determine what is visible and 
what is potentially visible in the scene. Entities not potentially visible to the viewer are not 
considered during frame rendering, and only those entities visible or potentially visible are 
rendered. This principle may be further extended to objects potentially visible but not readi- 
ly viewable, e.g., directly behind one’s view point. This reduction in polygons per scene 
ensures only pertinent information is provided to the user and further reduces the number 
of polygons that are required to be rendered. Implementing this feature with Jack ML and 


the LOD models further ensures the inclusion of 150 DI entities in NPSNET-IV.8. 1. 


D. ORGANIZATION 


A discussion of previous work related to LOD models is presented in Chapter II. It 


includes a description of the Jack ML model, LOD models currently in use in NPSNET- 





IV.8.1 and other sites, LOD construction considerations, and how IRIS Performer API soft- 
ware handles this information. 

Chapter II] is comprised of a discussion of the methodology used and final design 
for the DI entity LOD models in NPSNET-IV.8.1. A description is provided for the basic 
construction of the models, their associated ranges used for viewing purposes. 

In Chapter IV, a discussion is provided for the methodology and implementation of 
view volume culling as is done with the DJ entity LOD models. This chapter discusses 
some possible alternatives for implementing this technique, and an explanation of why one 
method is chosen over another. 

Chapter V discusses the final implementation of the Dude models in NPSNET- 
IV.8.1 and their associated motion algorithms required to support movement of a DI entity. 
This chapter also provides a concise report of the results of this research, including current 
NPSNET-IV.8.1 data as compared to previous data on frame rates while using the LOD 
models with and without view volume culling. Chapter VI concludes this research with a 
discussion of the results, and some insights for future work needed to further enhance the 


capabilities of NPSNET-IV.8.1. 








Il. PREVIOUS WORK 


Distributed Interactive Simulation (DIS) technology over the past several years has 
concentrated on the interaction of vehicles. The dismounted infantryman (e.g., the individ- 
ual foot soldier) has been largely ignored or was only represented as a static model. Recent- 
ly NPS, SARCOS Inc., and the University of Pennsylvania, under the direction of the Army 
Research Laboratory, demonstrated the ability to insert a fully articulated human figure into 
a DIS environment [DRPRATT2]. This advancement has paved the way for NPSNET- 
IV.7J to fully integrate humans in the virtual world. NPSNET-IV.7J has shown great im- 
provement in motion depiction from the previously scripted, non-distributed motion stud- 
ies that normally used stick figures. Before this work was implemented, several back- 
ground principles were exploited that now make human insertion in a virtual world possi- 
ble. They are: a) LOD and IRIS Performer Features, b) DI_Guy Development, and c) Jack 


ML, all of which are discussed below. 


A. IRIS PERFORMER FEATURES 
NPSNET-IV relies on the IRIS Performer API for graphics rendering. IRIS Per- 


former includes built-in functions that make frame rate manipulation possible for a given 
application. By taking advantage of these properties, it is possible to create an effective and 
realistic virtual world that is nearly unhampered by frame rate limitations [IRIS]. Some of 


the more applicable IRIS Performer features of interest are discussed below. 


1. Level of Detail Handling and IRIS Performer Software 


Level of detail models are useful because they easily exploit the principle that per- 
spective perceptions of discernible details and size reduce with increasing distance from the 
observer, as is demonstrated in Figure 1. Simply stated, objects further from the viewer 
need not be rendered using full polygon sets. This principle allows programmers to use 
lower resolution models for distant objects. Since finer details are less pronounced, they 


need not be rendered and may be left out of the model thereby putting fewer polygons into 





the graphics pipeline, allowing for higher frame rates. Important to note is that when poly- 
gons transform to less than one pixel, they effectively combine [DRPRATT1]. As distances 
increase, this natural occurrence aids in reducing visual detail and supports the use of LOD 
models. Several factors should be considered when rendering visualicons. Environmental 
effects such as clouds, fog, smoke, and haze will further reduce a viewer’s perception of an 
icon and lower resolution models may be more appropriate. Moreover, for most purposes, 
distance is the most significant factor in determining what type of model to use. As such, 

distance is the primary factor used in NPSNET-IV.8.1 LOD model design. While there are 


several types of LOD models in use, this section concentrates on icon processing. 
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Figure 1. Perspective Projection on Apparent Size 


a. Icons 
Whether an object is fixed or moving, the LOD switching algorithm is the 


same. As shown in Figure 2, the icon rendered, i.e., high LOD, medium LOD, or low LOD, 








is chosen based upon which bin the distance from the view point to the icon falls 


[DRPRATT1]. 
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Figure 2. Level of Detail Ranges 


Although this appears to be a simple switch based upon distance, there is no 
exact algorithm to determine where or when the switch should occur. Trial and error seems 


to work best. There are some rules to follow to help in this determination. Most important 








is the need to preserve the outline of the icon. As demonstrated in Figure 3, an outline 


change can be noticeable if it is done too close to the user view point [DRPRATT]1]. 
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Figure 3. Effect of Differing Outlines on Model Switching 


Color and texture are also important to consider when switching models. 
Colors and textures may not appear the same in the distant model as compared to the closer. 
Such changes may clearly indicate where a boundary exists. Here again, trial and error may 
be the most appropriate method to solve model LOD switching inconsistencies. 

Another fundamental problem, outline inconsistencies, can occur when 
switching models. As shown in Figure 2, the point of switch between models may be a dis- 
crete snap transition from one frame to the next, and a switch between models may occur 
in exactly one frame. This may draw attention to the transition, detracting from the overall 
affect of the scene. Blending allows two LOD models to be displayed at the same time, and 
it slowly blends differences from one to the other. While this method, possible with IRIS 
Performer, allows a smooth transition from one model to the next, the displaying of both 
models and the blending of alpha values during the transition actually increases the system 
load during the transition [IRIS]. A second method, morphing, allows users to define spe- 


cific points on the models and merges several polygons into one. Whether using snap 














changes, blending, or morphing, all methods are guaranteed to reduce final polygon 


count.[DRPRATT1] 


b. IRIS Performer Features 


IRIS Performer software allows programmers to define specific LOD mod- 
els to use for switching. By customizing such models, switching transition inconsistencies 
and system load problems may be reduced. Key to IRIS Performer’s LOD switching con- 
trol is the pfLOD command. Each child, i.e. LOD model, has a defined switching range, 
and the entire pfLOD has a defined center [IRIS]. Table 1 from the IRIS Performer Pro- 


gramming Guide shows some of the built-in Performer functions for use in LOD modeling. 


Function Description 


pfNewLOD Create a level of detail node. 


pfLODRange Set a range at which to use a 
specified child node. 


pfGetLODRange Find out the range for a given node. 
pfLODCenter Set the pfLOD center. 
pfGetLODCenter Retrieve the pfLOD center. 


a ce 





Table 1. IRIS Performer LOD Functions [IRIS] 


A sophisticated scheme for smooth switching may contain multiple LOD 
models that are grouped under a single LOD node for a specific geometry. This technique 
can ensure a smooth transition for a given icon. Figure 4 shows a simple node with several 
children numbered 1 through n. LOD 1 is the highest resolution model, with resolution de- 
creasing with increasing n. Additionally, each child may have several LOD components 


also defined. Associated with each node is a list of ranges that define the distance at which 





each model should be displayed. There is no limit to the number of LOD models that may 
be used in IRIS Performer [IRIS]. 





Figure 4. Level of Detail Node Structure [IRIS] 


The pfLOD node contains a value known as the center of the LOD process- 
ing. The center is the x, y, z location that defines the point used in conjunction with the us- 
er’s view point for range switching. Figure 5 shows an example using multiple switching 


models.[IRIS] 
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Figure 5. Level of Detail Processing [IRIS] 
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This example, from the IRIS Performer Programming Guide, shows a row 
of identical trees placed at increasing range from the view point. Double ended arrows in- 
dicate switching ranges for each level of detail. Range bracketing is used until the final 
range is passed, at which nothing is drawn. The pfLOD node’s switch range list contains 
one more entry than the number of child nodes for this purpose. [IRIS] 

The LOD switch ranges are processed before making the LOD selection. 
The goal of range setting is to switch LODs as objects reach a certain level of perceptibility. 
Items effecting this change are the size of the channel in pixels, field of view, and distance 
from the view point. Performer uses a channel size of 1024x1024 pixels and a 45-degree 
field of view as the basis for calculating LOD switching ranges.[IRIS] These help deter- 
mine what the user will see and how complex the scene may be. 

When switching between levels, model outline differences can be apparent 
when model discontinuities make the switch appear to change overall shape. IRIS Perform- 
er can relieve much of this by allowing users to define a blend zone where alpha values are 


blended for the closer model and the next model, making the transition much smoother 


[IRIS]. 


c. LOD Models in use 


As stated above, many examples of LOD models can be found throughout 
the virtual reality programming world. NPSNET-IV.8.1 currently uses LOD models when 
rendering tanks, helicopters and jets. These applications have proven effective in reducing 
polygon count while preserving the overall entity shape. Another form used in NPSNET- 
IV.8.1 is the “dead” model where an icon is turned black to indicate it is inactive. Other 
applications of LOD icons may be found in contemporary work world wide. 

An excellent example is the work of Funkhouser, et.al. of the University of 
California at Berkeley for the walkthrough of Soda Hall. This model is a detailed 3D model 
of a building complete with furniture and realistic lighting. Of note here is that while this 


is a building model and not a large scale virtual world, LOD models were necessary to pro- 
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vide high speed rendering and realistic walkthrough speed. For example, the designers used 
five LOD models for a desk to improve refresh rates and memory utilization. These models 
are adjusted so that transitions between levels are barely noticeable. The authors provide 
excellent descriptions of other models used in their system, and they chose to use blending 
techniques to achieve switching consistency. Little overhead was incurred during blends 


since differences in levels of complexity from one model to the next were very small.[TAF- 


UNK] 


B. DI_GUY 


In response to the now defunct Soviet threat, the first generation of low-cost, net- 
worked simulation systems, SIMNET or Simulation Network, was developed to simulate 
primarily company-scale tank battles. Using tank optics as the model, SIMNET was limited 
to an 89 degree field of view, less than half that of the 180 degree human view. This sim- 
plifying factor led to the creation of the terrain database based upon tank warfare so that 
only features related to this were rendered.[THORP] DIS, the successor of SIMNET is also 
vehicle based. As threats changed, emphasis has now shifted toward individual soldier in- 
tensive simulations, and the need for human simulation is growing. 

Small regional conflicts, Special Operations, and Military Operations in Urban Ter- 
rain are not currently cost efficient and do not lend themselves well to simulation. In these 
simulations, small units of foot soldiers interact to accomplish a mission. Clearly, the need 
to simulate and train based upon small scale conflicts has grown. Profound benefits of such 
simulations are certain to be well worth the effort. As such, Pratt et.al., demonstrated the 
new human in DIS for this purpose at the 1994 Individual Combatant Modeling and Sim- 
ulation Symposium, INCOMSS-94. In early SIMNET simulations, humans were represent- 
ed as a texture map, with changes in posture represented by different textures. Articulations 
were limited or not truly existent for the humans. DIS protocols have an extensible method 
of rendering articulations[IDA]. It was this feature that the INCOMSS-94 demonstration 


team made use of to articulate its model.[DRPRATT2] 




















For the INCOMSS-94 project, the model used was a Jack human figure created by 
the University of Pennsylvania. The model was converted to MultiGen Flight format so that 
NPSNET-IV.7’s IRIS Performer software could load the entity like other models. As seen 


in Figure 6, this model has 39 degrees of freedom in 17 separate joints. 
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Figure 6. Schematic of Human (DI_ guy) 


This representation for a DI, called DI_guy, was used in conjunction with the Jack 
software. Each entity in NPSNET-IV is part of a class of entities. From the class Ground 
Vehicle is derived the subclass Person for which a subclass dismounted infantry (DI_guy) 
was developed. The DI_guy subclass is based on the person vehicle, simply a vehicle such 
as a tank or jeep with restricted speed. The DI_guy supports 16 articulations, each change 
of which must be broadcast to the network in DIS format as part of a PDU used for control- 
ling ground-based entities, called the Entity-state PDU. This PDU provides the essential in- 
formation needed for its units, e.g., speed, heading, etc. All input for this class comes over 
a custom designed network socket and communicates with the Jack process, usually run- 


ning on a separate machine. Real-time raw data is manipulated by Jack. Jack manipulation 


13 





data is then sent to NPSNET-IV.7 and the DI_guy is updated on users’ displays. Commu- 
nications packets are sent at a rate of 30 times per second.[PTBARH] 

The DI_ guy process 1s a communications server, elevation server, and data display 
device. As a communications server, it dead reckons the human figure icons and formats 
DIS-compliant PDUs. A copy of the terrain database is maintained to provide ground ele- 
vation information and slope for a given location. One of the primary uses of the DI_guy 
is to debug the system by showing current location status and parameter values. The 
DI_guy data are updated at 60 Hz. Once packets are received, DI_guy computes elevation 
based upon x-y. This information can be passed to a user who is controlling the DI_guy to 
provide force feedback information if the DI_guy is being driven by a single user on some 
sort of simulation device. These data packets are then passed to Jack to compute the remain- 
ing joint angles for the DI_guy’s arms and legs. Once filled in, DI_guy packets are sent to 
the NPSNET-IV.7 display devices for updates in rendering. [DRPRATT2] 

Locomotion is based on the global velocity vector and global heading of the unit. 
Motion is a series of scripted sequences based on velocity. The current time is recorded at 
the beginning of each footstep, and the time at each update is used to determine the proper 
frame of the stride to display [DRPRATT2]. This calculation limits the overall speed of the 
DI_guy icon. All information is then broadcast to the network in DIS PDU format. Loco- 
motion computations are only performed when the figure is in the standing posture. All oth- 
er forms take a scripted roll and are sent to the network as the new posture. The posture can 
change only when the figure is not walking. Additionally, a mechanism is provided for 
forced stops, collisions, and stopping that are each handled differently and sent to the net- 


work for display.[. DRPRATT2] 


1. NPSNET-IV.7 Input Sources For DI guy 


Three display devices, two Head Mounted Displays and the Walk-In Synthetic En- 
vironment are used to interact as a DI_guy on NPSNET-IV.7. Since the user can see other 


non-Individual Soldier Mobility System (ISMS) input entities in a simulation, they read the 





DIS network for the status of these other entities, and rely on their data for correct network 


interaction.[ DRPRATT2] 


2. Network Implementation 


With ModSAF, NPSNET-IV.7 must coordinate the information for two logical net- 
works to provide an accurate representation of events as they occur. To avoid duplication 
of icons, a filtering system is used to discard DIS PDUs from the DI_guy. All ISMS con- 
nections are socket-based point-to-point dynamically assigned based upon a central request 
port. This connection makes it necessary to have redundant communication for each dis- 
played entity[ DRPRATT2]. Each data unit for a particular movement once executed is sent 


out in the form below. 


typedef struct { 


float wrist[3],elbow[1],shoulder[3];//degrees of freedom 
} ARM_ANGLES_TYPE; 
typedef struct { 


float toe[3], ankle[1],knee[3], hip[3];//degrees of freedom 
} LEG_ANGLES_TYPE; 


This is the type of information normally sent in a packet (not all inclusive), for each 
movement. Coordination of each move can become tricky if data locks and semaphores are 
not implemented before each modification and send to the network. To ensure consistent 
body orientation and posture, both ISMS and Jack inputs update the displays faster than the 
frame rate to account for the asynchronous nature of the SGI graphics pipeline and to 
achieve the minimal delay possible between action and display. ISMS sends out data as fast 
as possible (e.g., 30-60 Hz) to the DI_guy process, effectively overwriting any pending 
messages. The same is also done for the DI_guy back to the NPSNET-IV.7. This gives dif- 


ferent cycle times between processes and reduces the apparent latency in the display. 


[DRPRATT2] 
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A specific discrete movement (posture change) such as going prone is accom- 
plished by a button press, either on the keyboard or the throttle control while the user exer- 
cises a discrete transition. The simulated human executes a short script based upon the pre- 
computed posture transition graph. As soon as the posture transition script starts, a packet 
is sent across the network so the correct behavior is displayed by all stations on the net- 
work.[SMPRATT] 

General movement is updated each time through a main simulation loop. Each ac- 
tive icon (both local and remote) is notified to perform a moveDR operation. Upon receiv- 
ing this request, the entity dead reckons its new posture based on its last posture, the amount 
of time since the last move/update and the dead reckoning algorithm and data defined by 
the remote entity. For the DI_guy, if a state PDU has not been received in two time periods 
(10 sec), the local object corresponding to the remote entity is deactivated and the entity is 


removed from the network.[PTBARH] 


C. JACK ML IMPLEMENTATION 

Jack ML was developed at the University of Pennsylvania to perform efficient high- 
resolution human motion [BADLER]. The Jack ML software used in NPSNET-IV.8.1 is a 
newer version designed by John P. Granieri et.al. for the Team Tactical Engagement Sim- 
ulator (TTES) also presented at INCOMSS-94. This software package, the Jack Motion Li- 
brary or Jack ML, has been integrated into NPSNET-IV. 

The icon model used is actually a low-resolution model composed of 23 joints and 
50 degrees of freedom. Hands are modeled as mittens, and only significant joints and joint 


combinations are present [SMPRATT]. The model is composed of 478 polygons, and has 
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no fingers, spine, eyeballs, or clavicle [IPGRAN1]. As seen in Figure 7, this model is still 


quite detailed. 
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Figure 7. University of Penn.’s Jack ML Model. 478 Polygons 


As Jack ML is used with a Head Mounted Display, HMD, and most icon activity 
is rendered at a significant distance from the view point, this scale of model is more than 


adequate for modeling human interaction in the foreground [SMPRATT]. The University 
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of Pennsylvania possesses more detailed Jack ML models used for fine grain, highly de- 
tailed human modeling which is beyond the scope of the requirements for NPSNET-IV.8.1. 

Jack ML uses a set of scripted animations based on high-level behavioral and in- 
verse kinematic constraints that are played back based upon the current posture of the sim- 
ulated human, elapsed time, and motion pattern [JPGRAN2]. Jack ML changes postures, 
e.g., Standing to kneeling, based upon scripted static posture states that translate the figure 
to a different posture. The Jack ML file is composed of 10-15 primitive motions to translate 
the icon from one posture to another. This makes implementation much simpler when tran- 
sitioning from one posture to the next. As the original goal of the design was to provide a 
visual template for movement and not specifically to create the movement, scripting serves 
the purpose well.[JPGRAN1] 

For dynamic posture changes, i.e., the velocity vector is not zero as in walking or 
crawling, a combination of scripted files is used to produce the effect. Walking, for in- 
stance, 1s begun when the velocity vector provided to Jack ML is non-zero. An initial step 
is executed to create a smooth transition from static to dynamic posture. Next, a cyclic state 
of scripted walking is executed and continues until a change in the velocity vector is noted, 
either a zero value or a change to run. When running, another set of cyclic state files to de- 
pict running are executed. A threshold value is set to return the icon to walking from run- 
ning if this occurs.[JPGRAN1] 

For NPSNET-IV.8.1, the animations used are modified in real time from user input. 
Since state transitions are scripts, and dynamic transitions are table-driven scripts, these can 
be overridden to more closely model a specific action. Currently, work is underway parallel 
to this thesis to add more mobility to the Jack ML model [SMPRATT]. Another scripted 
motion of a medic action is provided with Jack ML and is currently being implemented and 


further updated in NPSNET-IV.8.1. 
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1. Jack ML Control 


Jack ML icons are controlled via several mechanisms. Speed and direction can be 
controlled by either keyboard or throttle and stick. Walking begins when the throttle is 
moved forward, advancing the velocity vector. By controlling the velocity and enumeration 
bits of the DIS PDU, Jack ML’s motion is adequately modeled for dynamic postures. Sim- 
ilarly, static postures are executed via a button press on either the keyboard or throttle. As 
discussed before, this prompts the execution of a scripted transition to model user inten- 
tions[SMPRATT]. Real time modification of movement is used to move Jack ML’s head 
which is tracked by the HMD. This adds to the realism that the user is in the virtual world 


as a human. 


D. SUMMARY 


In past virtual reality systems, human models have been represented using unreal- 
istic static icons, or intricately designed icons which were computationally expensive. Re- 
cent developments such as the DI_guy, and Jack ML have greatly enhanced human inter- 
face in large-scale virtual reality systems. In order to further advance the human interface, 
more human icons are required per scene. The concept of level of detail modeling is not 
new, however, this is the first time this principle has been applied to and combined with 
human behavior to extend the capability of a system. LOD models are critical to increasing 


the number of human icons per scene while maintaining a high frame rate. 
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Il. MODEL CONSTRUCTION 


The premise driving this research was primarily speed, specifically frame rate. Jack ML 
was successfully implemented in NPSNET-IV.7J in December 1994. Jack ML is more real- 
istic and anatomically correct than DI_guy, and it offers greater potential in simulating 
human movement. However when numerous instantiations of Jack ML are required, e. g., 
more than 20 entities, the computational cost of articulating joints becomes prohibitive. In 
order to overcome this limitation, level of detail models called Dude were developed. 
Current designs display the high resolution Jack ML model when distances between the 
user’s view point and the human icon to be rendered are 100 meters or less. When the 
distance exceeds 100 meters, a Dude is rendered, instead of the Jack ML model, in one of 


its three level of detail models: Dude_medium, Dude_medium_far, or Dude_far. 


A. IRIS PERFORMER API TOOLS USED 


Dude models rely heavily on IRIS Performer API functions. Key to understanding 
the Dude model construction is a familiarity with the IRIS Performer functions pfNode, 
pfGroup, pfDCS, and pfSwitch. 


1. PfNode 


A pfNode is an abstract type. IRIS Performer does not provide any means to explic- 
itly create a pfNode. Rather, the pfNode routines operate on the common aspects of other 
node types. These nodes include: pfGeode, pfGroup, pfDCS, pfScene, pfSwitch, and 
pfLOD; all of which are vital to the Dude models. Any IRIS Performer node is implicitly 
a pfNode, and a pointer to any of the above nodes may be used. Only a subset of the pfNode 


types actually contain geometry. These are known as “leaf nodes” in IRIS Performer.[IRIS] 


2. PfGroup 


A pfGroup is the internal node type of the IRIS Performer API hierarchy and is 
derived from the pfNode. A pfGroup has a list of children which are traversed when a group 


is traversed. Children may be any pfNode which includes both internal nodes (pfGroups) 
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and leaf nodes (pfNodes). Other nodes which are derived from pfGroup may use that 

pfGroup API. IRIS Performer nodes derived from pfGroup are: pfScene, pfSwitch, pfLOD, 
pfSequence, pfLayer, pfSCS, and pfDCS. PfAddChild appends a child to the group. PfRe- 
moveChild removes a child from group. The bounding volume of a pfGroup encompasses 


all of its children. [TRIS] 


3. PfDCS 


A pf{DCS (Dynamic Coordinate System) is a pfSCS (Static) whose matrix can be 
modified. A pfDCS can be used in place of a pfSCS, or pfNode. PfNewDCS creates and 
retums a pointer to a pfDCS. The initial transformation is the identity matrix. Movement, 
as is the case for the Dude models, can be set by specifying a matrix or translation, scale 
and rotation. Specific movements are then accomplished through the use of the pfDCS 
functions “pfDCSTrans” for translations, and “pfDCSRot” for rotations [IRIS]. These 


functions make Dude model movement possible. 


4. PfSwitch 


A pfSwitch is an interior node in the IRIS Performer node hierarchy that selects one, 
all, or none of its children. It is derived from pfGroup so it can use pfGroup API to manip- 
ulate its child list. PiSwitchVal sets the switch value of sw to val. Val may be an integer or 
symbolic token. It may take the form “PFSWITCH_ON” or “PFS WITCH_OFF” in which 
case all children or no children are selected.[IRIS] These calls are used to select the proper 


Dude model, as well as children of that model. 


B. NODE HIERARCHY 


Since interdependencies lie between the three models of Dude, it was possible to 
contain the information for all the models in one design structure. Best represented in 
Figure 8, a nodal hierarchy system was used. To summarize this structure, the highest node 
is a group node called “rootGP.” It is this node that gets attached to the scene graph. Direct- 
ly beneath this node is a DCS node called “hullIDCS” which allows the distance-specific 
chosen model to be rendered to be moved to the correct position and orientation in the 


scene. Moving down below the hullDCS level finds a switch node. This first switch, called 
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“sw’’, is used to select between the Dude_far model and the other two. If the distance is 
sufficiently close enough to render a Dude_medium or a Dude_medium_far the switch is 
set to its first child. If the distance is sufficient to render a Dude_far, the switch is set to its 
second child. If the distance is too great for a Dude_far icon or if the model is not in the 
view frustum the switch is turned to off. The second child of “sw” is a DCS node called 
“far_bodyDCS” allowing Dude_far to be rendered and oriented properly in the scene. This 
node has only one child, a group node named “far_body” which contains the appropriate 
geometry to render Dude_far. The first child of the switch “sw”, used only for 
Dude_medium and Dude_medium_far, is a group node called “torsoGP.” Since both 
models have identical torsos the same geometry for both is used. The group node holding 
this common torso is labeled “body” which has no children of it own. Both models also 
share the same face and head. Since the head may be articulated, a DCS node is a child of 
the “torsoGP” node. This DCS node is called “headDCS” and allows the heads of two 
models to be articulated. HeadDCS has a child which is a group node containing the geom- 
etry of the head called “skull.” The second child is also a group node containing the appro- 
priate face geometry, either Rick or Duane, and is labeled “‘face.”’ 

The remaining four child nodes connected to “torsoGP” are for each limb. The 
structure for each limb is basically identical so only one limb shall be discussed. For exam- 
ple, the right arm is rendered for Dude_medium as follows: The right arm must be articu- 
lated so the first node connected to “torsoGP” is a DCS node called “armrightDCS.” It has 
a Child, a switch node called “sw2” which toggles between the Dude_medium or 
Dude_medium_far arm. If Dude_medium_far is selected the second child of “sw2” is 
rendered. This child is the arm of Dude_medium_far and its geometry is contained in a 
group node called “armrightmed.” Since for this example, Dude_medium is selected the 
first child of “sw2” is used. This first child is another group node called “armrightGP” and 
has two children of its own. The first child is a DCS node corresponding to the right elbow 
joint called “armrightlowDCS.” Attached to this DCS is a group node containing the lower 
right arm geometry for Dude_medium called “armrightlow”. The second child of 


“armrightGP” is the right upper arm geometry stored in a group node named “armrightup”, 


23 





peated three more times one for the left arm 


e medium. This structure is re 


the bicep of Dud 


and one each for the nght and left leg. 


CheadDCs> 
CheadGP > 


Gskull)  Caace) 


Camleftbes > 


Guia 


armleftGP > 


armleftup 


armleftlowDCS 


armleftlow 


off, 
CSW 


CsoP—— Cos) 


armrightDCS legleftDCS 


Cwiy Laff awry Loft 
armrightmed llegleftmed | 


armrightup | legleftup 


armrightlowDCS 


Figure 8. Node Hierarchy for the Dude Structure 
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C. MODELS 


Three distance specific models were developed each representing a different level 
of detail. Using spatial-distance relationships as discussed in Chapter II, recall that as 
distance from the viewer is increased the ability to distinguish detail, i.e., individual joint 
movement and articulation, decreases. This perception continues to degrade with increas- 
ing distance such that the distance will reach a level such that no joints can be distinguished. 
This principle forms the foundation for the creation of the Dude models. All three of the 
models share the common property of uniform selection. They can be attired in either desert 
camouflage or woodland camouflage as the user dictates. Additionally, the two closest 
Dude models have faces which can be textured with one of two choices; “Rick” the friendly 
agent, or “Duane” the enemy agent, much the same as is done with the Jack ML model. 
Figure 9 shows all three models side by side. Similar in appearance, the total number of 
polygons per model drops significantly from the left model to the right model, with the left 
model, Dude_medium having 50 polygons, the middle, Dude_medium _far having 30 
polygons, and the right model, Dude_far having three polygons. In this figure, 
Dude_medium has the face of Duane, and Dude_medium_far has the face of Rick. Tables 


2 and 3 show polygon and articulation data for the various models in use. 
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Table 2. Polygon count and DOFs of Models 
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Figure 9. Dude Models 
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1. Dude medium 


Dude_medium is the highest level of detail Dude model. It is rendered when the 
viewer’s eyepoint is from 100 meters to 150 meters away. Although it is clear that this 
model bears little resemblance to Jack ML in design, several basic Jack ML properties were 
integrated into the Dude_medium model. These include the physical dimensions of Jack 
ML to include height, width, and depth. Varying somewhat from the overall shape of Jack 
ML, Dude_medium has fewer joints and significantly fewer polygons; a primary goal of 
this design. Dude_medium has a total of 50 polygons reduced from Jack ML’s 486. The 
joints or rotation points are as follows: Head, Left/Right Shoulder, Left/Right Elbow, Left/ 
Right Hip, and Left/Right Knee. The basic structure of Dude_medium is depicted in Figure 
10. 


2. Dude_medium_far 


Dude_medium_far is the second highest level of detail Dude model, being 
displayed when the distance to the viewer is from 151 meters to 200 meters. Identical in 
design to Dude_medium, Dude_medium_far has the same physical dimensions as 
Dude_medium, and the only way to distinguish the two models is through the reduced 
number of joints. Dude_medium_far‘s rotation points are the Head, Left/Right Shoulder, 
and Left/Right Hip joints. Here again a significant savings from reduced polygon count was 
achieved through the elimination of secondary joints and additional polygons needed for 
articulation. For example, the arm is one piece versus two pieces for Dude_medium. This 
elimination of joints results in a model composed of merely 30 polygons and five rotation 
points as is depicted in Figure 11. Such a reduction is still perceptually effective and does 


not detract from the reality of NPSNET-IV.8.1. 


3. Dude_far 


Dude_far represents the lowest level of detail of the Dude models. Dude far is used 
when the distance from the viewer is 201 meters to 350 meters. This model is strikingly 
simple consisting only of 5 polygons and no joints. Dude_far has the same overall height 


and width as the two previous models, but its design represents a significant departure from 
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human characteristics. However, further extending the principles discussed in Chapter IJ 
regarding visual perceptions proves this design is still quite effective in conveying the 
image of a distant entity in the user’s view frustum. Dude_far is composed of only three 
polygons, two along the x and y axis respectively. To be able to be viewed from above the 
third polygon was placed on top of the x and y polygons. With no joints, no articulations 


are possible nor required for this level of detail. As is depicted in Figure 12, the resulting 


model used to represent a distant human is successfully achieved with only three polygons. 
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Figure 10. Schematic of Dude_medium 
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Figure 11. Schematic of Dude_medium_far 
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D. CONSIDERATIONS 


As discussed in Chapter II, IRIS Performer provides a built-in series of nodes and 
function calls to handle levels of detail in the form of pfLOD nodes. In the original node 
hierarchy design of the Dude models, we utilized these node types in place of the switch 
nodes now in use. Testing under various load conditions determined conclusively that 
pfSwitch nodes worked much better to preserve frame rates than did pfLOD nodes. Where- 
as the pfLOD node automatically shifts between models, the pfSwitch node required the 
creation of a unique algorithm to determine when the shifts should occur effectively replac- 
ing the pfLOD function. The algorithm used to perform this switching for Dude models is 
a simple extension of the distance formula. The two sets of x, y, and z coordinates used are 
the positions of the view frustum and of the Dude model. With this calculation the pfSwitch 
is set to the appropriate child. 


1. The Dude Loader 


To get the proper geometry into the group nodes of the IRIS Performer node hier- 
archy, a custom loader was developed consisting of files “dude_funcs.h” and 
“dude_funcs.cc”’. The loader is called with the type of Dude requested, either friend or foe. 
Space is allocated for the node hierarchy and then the loader uses three functions to build 
the three Dude models. The three functions each get the data to construct their models from 
three different data files, called within each function respectively. The models are inserted 
into the node hierarchy at the proper positions and as a result the entire Dude tree is 
constructed. The geometry of the tree is contained in a global structure defined in the file 


“‘dude.h.” The structure is named DUDE _GEOM. 


2. DUDE_GEOM Structure 


DUDE_GEOM is the basic structure or node hierarchy to hold the geometry, Le, 
vertices of polygons, texture coordinates, normal planes, etc., of the dude models. The node 
hierarchy explained earlier was placed in the DUDE_GEOM structure to save shared 
memory. In addition to containing the node hierarchy, DUDE_GEOM also contains all the 
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variables needed when the data files are read and manipulated by the custom loader portion 


of the program. 


3. The Dude Class 


The file “dude.h” also defines a class called DUDEClass. A class structure is 
required because we must be able to instantiate more than one Dude model at a time. It is 
also required because NPSNET-IV is C++ based. Without this structure, problems arise if 
more than one Dude is to be implemented and used independently; e.g., independent 
manipulation of a Dude model where more than one existed, was not possible. Using only 
one structure or node hierarchy meant that the information in that structure is common to 
all Dude models. This is sufficient if the Dudes are required to have the exact same posi- 
tions and orientations. However, NPSNET-IV.8.1 requires multiple independently 


controlled Dudes. Thus a Dude class was necessary to achieve this control. 


4. The Constructor 


The action of the constructor is to clone the node system built by the loader for each 
instantiated Dude model. In this fashion, when a Dude is declared of type DUDEClass, i.e., 
an independent model, the entire node system is cloned and made available explicitly for 
that particular Dude. Also in the constructor the x, y, and z position of the Dude is estab- 
lished and the instantiated model is attached to the scene graph. Finally a single point is 
attached to the center of the Dude to be used for view volume culling, discussed in Chapter 
IV. 


E. VARIABLES OF THE CLASS 


The class DUDEClass was written in an object-oriented fashion and consequently 
maintains all of its own state information. This information includes all nodes of the type 
and number discussed previously that are required to properly be able to clone the structure 
DUDE_GEOM, its x, y, and z position with respect to the scene graph, whether it is inside 
or outside of the view frustum, the distance to the user’s view frustum, and all the variables 
to control each of the models articulation points to perform its three movement functions 


of walk, kneel, and going prone. 
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1. Member Functions 


DUDEClass includes its own functions to provide the Dude models with a variety 
of different movement capabilities. The class has a walk, kneel, stand, and prone function 
which work for all three different models irrespective of the model. Posture transitions are 
merely snap changes in which the model’s posture is changed in only one frame. There 
exists no posture transition algorithm to display a Dude model as it shifts from standing to 
prone, for example, as is done with the Jack ML model. Posture changes for the Dude_far 
model are simple rotations and translations similar to the articulated models, but much 
simpler in design. The class also has the ability to attach and remove Dudes as children of 
the scene graph as well as the ability to place a Dude model at any x, y, and z position within 
the scene when required. As was discussed previously, the DUDEClass has its own func- 
tion to determine if each Dude should be drawn or not and if drawn, which Dude level of 
detail model to draw. The following pseudocode shows the basic algorithm for selection 
and culling: 

-pass channel 
-test if PtlsecFrust 
~>yes - calculate distance from frustum to model 
- switch to correct model 


->no - switch to off 


2. Performance Figures 


To test the Dude models a driver program was developed before the models were 
integrated into NPSNET-IV.8.1. This driver instantiated 200 Dudes and randomly placed 
them throughout a 500 meter by 500 meter grid. Level of detail switching between models 
was apparent in the test run. The goal of this testing was to achieve a maintainable frame 
rate of 20.0 frames per second. Average data for the numerous versions is summarized as 


shown in Table 4. 
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LOD Handling Culling Method Intersection Test Frame Rate 


pfLOD pfAdd/RemoveChild bounding spheres 
PointInFrustum 
pfSwitch bounding spheres 


PointInFrustum 

pfSwitch pfAdd/RemoveChild bounding spheres 
PointinFrustum 

pfSwitch bounding spheres 
PointInFrustum 





Table 4. Performance Data for 200 Dudes 
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IV. ENTITY CULLING 


A. INTRODUCTION 


While LOD usage is effective in maintaining a high frame rate, it may not be 
adequate by itself. With increasing numbers of entities in a system, e.g., tanks, aircraft, 
ships, missiles, etc., it becomes necessary to remove non-essential items or information 
from the active database so as to preserve frame rates in favor of the immediate view. Entity 
culling is useful for removing objects not visible to the user. In the case of the dismounted 
infantryman figure and its supporting LOD models, entity articulation and management 
become a computationally expensive task when multiple models are in the scene. By cull- 
ing out entities that are not visible, we can effectively reduce the number of articulations 
required by removing and not managing the culled model. Important to the culling process 
is the point in the active environment that entities are culled. As culling can be an expensive 
calculation if not performed wisely, programmers must decide when it is economically 
feasible to cull an entity or continue to draw it. Removal of an entity in the Draw process 
is the most expensive operation, as the entity has already been sent through two pre-render- 
ing processes. Simply managing the entity may be a less expensive option. It is possible to 
remove yet manage a model that may be just beyond the view frustum so that when it comes 
into view, the proper geometry is rendered. These two techniques are known as view | 
volume culling, and range management. View volume culling is the simpler of the two, and 


itis most widely used. 


B. VIEW VOLUME CULLING 


View volume culling is achieved by testing the view frustum against a test object. 
As shown in Figure 13, an object is rendered if the test point or volume is within some range 
of the view frustum. If the object is in the frustum, it is rendered, otherwise it is not. As 
shown in Figure 13, icons A-E are present in the scene. Clearly, icon A is within the view 


frustum so it would be rendered. Icon B is to the right of the view frustum and would not 
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be rendered. Icon C lies beyond the defined far clipping plane of the scene, hence would 
not be rendered. Icons D and E present unique problems in view volume culling. Icon D is 
on the right boundary of the view frustum, so an algorithm and bounding volume must be 
used to determine if the object should be rendered. Since the bounding volume is partially 
within the view frustum but the icon is outside of the frustum, it represents a special case. 
Icon E presents a similar problem since it is in front of the defined near clipping plane. A 
similar approach to icon D is required for icon E. These principles are the foundation for 
view volume culling developed for the Dude models. In these models, we designed two test 
regions in order to discover which would produce better results. These test regions are a 


bounding sphere and a single point. 


Far Clipping Plane 


VIEW FRUSTUM con E 


Near Clipping Plane 


Vv Eye Point 


Figure 13: Basic View Volume Culling Testing 
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C. POINT IN FRUSTUM 

Recall from Chapter IIT that for each instantiation of a Dude model, the constructor 
ensures that specific properties required for each model are included. One such property is 
the attachment of a single point to each Dude model for view volume culling purposes.The 
point attached to the Dude is of type pfVec3 so as to allow it to be attached to the exact 
center of the Dude, as shown in Figure 14. This point allows the usage of an IRIS Performer 


function call “pfPtIinFrust” to determine if the Dude is in the view volume. 


iN 
l Dude Model 
+S Ls 


| 


Figure 14: Culling Point of Dude using a single point 
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The “pfPtInFrust” function returns a Boolean and depending on that value the main 
pfSwitch at the top of the Dude node structure is set to either draw the proper Dude model 


or to draw nothing. Figure 15 shows culling using the “pfPtInFrust’ function. 
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Figure 15: View Volume Culling using pfPtInFrust 
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The Boolean value returned by testing with “pfPtInFrust” is one of four values: 
“PFIS_FALSE” indicating the point is entirely outside of the frustum, “PFIS- MAYBE” 
indicating the point is partially inside or entirely inside the frustum, and “PFIS_TRUE” 
indicating the point is entirely inside the frustum. If the computation cannot be done trivi- 
ally, the function returns “PFIS_MAYBE” as in the case of a point possibly inside the frus- 
tum. Since speed is paramount in culling, non-trivial solutions return “PFIS_. MAYBE” 
instead of spending additional time determining whether the point is inside or outside of the 
frustum. [IRIS] This function result was easily used for our purposes to render a Dude 
model. 

The “PtIsectFrust” method has its advantages and disadvantages. The advantage to 
the point method is that it is a single point having no distinct geometry. This makes its 
implementation simple in that no geometry must be passed for each instantiation. Its weak- 
ness is that because it is a point, it must be either inside or outside of the view frustum for 
culling to achieve its goal. This means that an icon may be partially within the view frustum 
and still not be rendered because the point is still outside. Conversely, an icon that should 
be culled out, e.g., one on the edge of the frustum, may be rendered until the culling point 
is outside the frustum. For both cases, a return value of “PFIS_MAYBE” is usually indic- 
ative of this condition, and is used to render the icon in our case. “PFIS_- MAYBE” was rare- 
ly returned when using the “PtIsectFrust”. Based upon our original driver program, not 
actually NPSNET-IV.8.1, and data shown in Table 5, the “PtIsectFrust” provided a slight 
computational advantage over the bounding sphere in the form of one frame per second 
increase during the initial loading. This increase was discovered while running the program 


with 200 Dude icons on the Onyx/4 R2 machine “Meatloaf”. 
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LOD Handling Culling Method Intersection Test. Frame Rate 


pfLOD pfAdd/RemoveChild bounding spheres 
PointInFrustum 

pfSwitch bounding spheres 
PointInFrustum 


pfSwitch pfAdd/RemoveChild bounding spheres 
PointInFrustum 

pfSwitch bounding spheres 
PointinFrustum 





Table 5: Performance Statistics for 200 Dudes 
D. BOUNDING SPHERE 


The second method examined in the course of this research was to utilize bounding 
spheres for visual culling. In a similar procedure to points, a bounding sphere was attached 
to each Dude model. Using another IRIS Performer function call “pfSpherelIsectFrust” 
which also returns a Boolean, the pfSwitch is manipulated exactly the same as described 
above. Figure 17 shows the placement of the bounding sphere on the Dude model. Similar- 
ly, Figure 18 shows culling using the “pfSpherelIsectFrust.” Here again, the function returns 
a Boolean value having one of the four values discussed above. As the sphere is much larg- 
er than the point, “pfSpherelsectFrust” returns significantly more results of 
“PFIS_ MAYBE,” especially when a model is near or just beyond the edge of the view frus- 
tum. This result is easily tailored to render the icon. 

The bounding sphere method also has its advantages and disadvantages. It has a 
distinct geometry that must be allocated and passed for each instantiation. If shared memo- 
ry is critical, this could be more costly to the application. However, because this is a true 
bounding volume, it is much easier to predict its implementation when used for culling. If 
an entity is near a view frustum boundary, the sphere gives a more reliable return value than 


does the point-in frustum technique. The use of “pfSphereIsectFrust” was discarded after 
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testing which revealed that the point-in-frustum method offered a marginally better perfor- 


mance as shown in Table 5 above. 


Dude Model 
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Figure 16: Culling Sphere for a Dude Model 
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(Dude Not Rendered) 


View Frustum 


Figure 17: View Volume Culling using pfSpherelsectFrust 











Figure 18 shows a human icon with only its shoulder on the periphery of the view 
frustum using both the point intersection test, and a bounding sphere. As this figure shows, 
the icon is in the same location in the virtual environment. It fails the culling test when 
using “PtIsectFrust’, since the point is outside of the view frustum, and the icon is not 


rendered. It passes when using a bounding sphere, and the icon is rendered. 






Bounding Sphere Method 





(Dude Renderec 





Far Clipping Plane 





View Frustum 


Point Method 


Figure 18: Point vs. Bounding Sphere in Culling 
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E. ADDING/REMOVING CHILDERN OF THE SCENE GRAPH 


After determining that the point-in-frustum technique was better to manage the 
scene, an efficient method was needed to add and remove models from the scene graph. The 
initial development removed Dudes from the scene graph that were not in the view frustum. 
Models were removed using the IRIS Performer “pfRemoveChild” function call. 
Conversely when dudes needed to be added to the scene graph after returning to the view- 
er’s frustum, the “pfAddChild” function call was used. Analysis of this method showed 
that, while useful, the calls were very expensive in terms of speed. Investigating other less 
costly methods resulted in utilizing “pfSwitchVal” function to set the pfSwitch node to 
“off” when a model was to be removed, and “on” when returned. When using “pfSwitch- 
Val’ the entity is still attached to the scene graph. When using “pfAdd/RemoveChild,” the 
entity is removed from or added to the scene graph, expensive operations in terms of CPU 
usage. This expense is realized in reduced frame rates, the opposite effect we desired. After 
further testing, analysis of run data showed “pfSwitchVal” offered a marginally better 


performance as shown in Table 5. 


F. SGI RENDERING PROCESSES 


As shown in Figure 19, the NPSNET-IV.8.1 pipeline is composed of three main 
processes, the Application process, the Culling process, and the Drawing process. When 
culling entities, CPU and memory management gains are more efficient the earlier in the 
three-step process one can make them. For example, the most computationally expensive 
culling procedure is performed in the Draw process. Since the entity must pass through two 
rendering processes prior to reaching the Draw process, one must decide if it is economical 
to cull the entity or simple render it. The Draw process culling is a fine grain process, deal- 
ing with specific entities and what is in their view frustum. By the time an entity is being 
handled by the Draw process, memory allocation, pointers, and textures have been loaded 
and any manipulation of this icon will involve each attribute of the program. The Culling 


process, or simply Cull, offers a less expensive alternative to entity culling. If one can elim- 
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inate objects or icons at this level, much of the loading and allocation is saved before the 
process is passed on to Draw. Further up the pipeline is the Application, or App, where 
whole databases and textures can be eliminated to increase loading and rendering speed. 
For our purposes, NPSNET-IV.8.1 handles the App when loading textures and terrain data- 
bases upon entity instantiation. Icon range management, part of the Dude software, is 
performed in the App process. Finally, fine grain culling based upon the view frustum is 


handled in the Draw process. 


APP CULL DRAW 


Figure 19: The Basic NPSNET-IV Pipeline 


G. ICON RANGE MANAGEMENT 


Range management was implemented in the Dude software in the interests of reduc- 
ing the number of articulations processed for all entities present in a user’s virtual environ- 
ment. The concept of range management is to construct a multi-level monitoring system to 
determine when human icons should be managed, rendered, and articulated. This allows us 
to have multiple entities present in the virtual environment that are either managed and 
rendered, managed and not rendered, or not managed and not rendered. Figure 20 show the 
basic principles employed in the Dude software for range management. Here, as is 
discussed in section D above, range management takes advantage of the fact that it is less 
costly to remove entities in the App process than in the Draw process. For entities outside 
of the view frustum, they are not rendered thereby saving frame rates. For objects beyond 
the range of the frustum, in our case 260 meters, they are neither rendered nor managed so 
that no articulation calculations are computed further increasing frame rates. This repre- 


sents a significant savings for DIS-based systems where every entity, regardless of its loca- 
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tion in the virtual world, broadcasts its location to all other systems. When entities come 
within the 260 meter range, they are then managed so as to be ready to render the proper 
geometry and activity should they come into the view frustum. Note that 260 meters was 
only used for testing purposes, and does not represent a fixed standard. This distance can 
be changed as a programmer desires for each specific application. Management of icons is 
achieved by setting up a range around the driven entity (the user), and determining based 
upon the velocity vector and heading each other entity in the environment, if they will be 
coming into the range of management or view. This calculation is performed for each DIS 
update cycle (normally 5 seconds) for each icon, whether it is the driven entity or one that 
is dead reckoned by the system. The difference between the range filter and the maximum 
viewing distance should be more than the distance travelled by the entity in one update 
cycle to ensure that the entities are managed before they enter the visual range 
[SMPRATT]. In the case of the far clipping plane, we have a 10 meter buffer in which a 


entity will be managed before it is rendered. 


View Frustum 


Not Rendered 
Not Managed 


Rendered 
Managed 


View Point 





Figure 20: Range Management of Entities, after [SMPRATT] 


From Figure 20, we can step through the multi-level custom culling algorithm and 


see the results. Icon A is outside the range filter distance of 260 meters so it fails to meet 
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the first level range check. All information concerning icon A is discarded. Icons B and C 
both lie within the range filter, but outside the view frustum. These two icons both fail the 
second level test, so they are only managed and are not rendered. Icon D presents a special 
case, since it is behind an obstacle. It is still managed and rendered, although it could be 
discarded using a line of sight calculation. In the interest of speed, we chose a liberal 
approach for this special case, and we manage and render the icon as long as it is in the view 
frustum. Of the five human icons, only icon E is clearly visible, and it will be rendered and 


articulated along with icon D.[SMPRATT] 


H. SUMMARY 


Entity culling is extremely effective and important to preserving frame rates. 
Although this is not a new concept, this is the first time it has been applied to articulated 
humans in NPSNET-IV. By removing non-visible entities, one can preserve frame rates by 
discarding objects outside of the view frustum. To further ensure frame rate preservation, 
range management is used to reduce the number of managed, articulated icons in the virtual 


environment. Both methods prove highly effective in maintaining real-time performance. 
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V. NPSNET-IV INTEGRATION 


A. MODELS IMPLEMENTED 


After extensive testing and development in our stand-alone driver program, the 
finalized Dude model designs and functions were integrated into NPSNET-IV.8.1. This 
integration was a major undertaking since all data for their design, LOD switching infor- 
mation, and all associated motion algorithm software had to be tailored to work in 
NPSNET-IV.8.1. The following three close-up figures show the final version of models 
implemented in NPSNET-IV.8.1. Figures 21 and 22 show the Dude icons in two snap tran- 
sition postures available to the Dude models. Figure 21 shows the models in their kneeling 
postures, while Figure 22 shows them in their prone postures when viewed from above. 
These figures also show the models with the two uniforms, woodland green or desert tan 
camouflage, and caricatures, Rick or Duane, available. Figure 23 shows the three Dude 
models mid-stride when walking. 

For each human figure in NPSNET, we use four different models to achieve multi- 
ple level of detail (LOD) polygonal representations. If the figure is not within the viewing 
frustum, IRIS Performer will prune the models from the scene graph during its cull process 
and no human figure will be drawn.(However, it will be articulated unless otherwise spec- 
ified). When the figure is within the viewing frustum, Performer’s level of detail selection 
and model switching functions will automatically trigger the appropriate model to be 
displayed depending on the pre-specified LOD distances and the viewing distance between 
the user’s eye point and the figure. When the distance is small, the user is viewing a human 
figure which has full articulation of all the major body parts. However, when a user is view- 
ing a human figure which is located off in the distance, the figure shown is actually much 
less complicated in appearance, and it has fewer articulated parts. Ultimately, as the view- 
ing distance exceeds 200 meters, the human figure simply appears as a collection of just 


three polygons. During run-time, the user is unable to perceive a noticeable loss in figure 
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resolution because his ability to see details and articulated motions of objects decreases 
steadily as the objects move further away. To maximize performance, we chose to avoid 
the high costs of blending two different LOD models together at the LOD transition points 
and allow instantaneous model switches to take place. The results are still quite visually 
acceptable in a dynamic environment. Figure 24 shows all four human models used in 


NPSNET-IV.8.1 side by side, and views from various ranges. 





Figure 21: Dude Models: Kneeling Posture 
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Figure 22: Dude Models: Prone Posture (as viewed from above) 


Figure 23: Dude Models: Walking 
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Figure 24: Comparison of Dude and Jack ML Models 


The intention of the integration of the Dude models is not only to provide LOD 
support for the Jack ML icon, but also to provide a stand-alone Dude model in NPSNET- 
IV.8.1. Results obtained from our independent program, showed that a provision for a 
Dude-only mode of NPSNET-IV.8.1 would be useful in order to add more humans in 
NPSNET at the minimal cost to the system. For this reason, two distinct NPSNET entities 
with Dude support are available. These are: “dude,” providing three LOD models 


composed of Dude models allowing Dude-only capabilities, and “jade” for full Jack ML 
support with Dude and Jack ML models. 


B. SOFTWARE ADDITIONS/MODIFICATIONS 


In order to properly integrate the Dude software into NPSNET-IV.8.1, several 


modifications to existing software were required. These modifications were made using the 











SGI ClearTool, a new configuration management system controlling software revisions to 
NPSNET-IV.8.1. Using ClearTool, we had our own version of NPSNET-IV.8.1 to edit and 
test before fully integrating our changes into the final system. This new method worked 
relatively well, allowing us to make the necessary changes without affecting the existing 
system until we had completed the integration. As a new configuration management 


system, however, there were some “bugs” which had to be worked out in using ClearTool 


as well. 


1. File Distribution 


As the first step to integrating our software into NPSNETIV.8.1, we brought our 
entire thesis/help directory under configuration management by distributing our existing 
files into the appropriate directories. The header files (dude.h, dude_funcs.h, and jade.h) all 
went under “npsnet/src/entities/finclude” while the “.cc”(source) files (dude.cc, 
dude_funcs.cc, and jade.cc) went under “npsnet/src/entities/dude”. The model data files 
(dude_friend.jcd, dude_enemy.jcd, dude_med_model.jcd, dude_medfar_model.jcd, 


dude_far_model.jcd) all went under “npsnet/datafiles/human’’. 


2. Dynamic Data Addition 

“Dynamic.dat” is a file containing all the dynamic models used within NPSNET- 
IV.8.1. This file was modified to include Dude and Jade models. In this file, a new unique 
letter code for both the Dude and Jade model is defined. Dude is assigned to “U”’, while 
Jade is assigned to “V”’. This allows NPSNET-IV.8.1 to read and load the associated data 
for various types of models. Currently NPSNET-IV.8.1 is able to load University of Penn- 
sylvania “tips” files, and now our Dude and Jade models. The letter is used strictly by the 
model file loader routine in “netutil.cc” discussed below. For unique entity identification 
purposes, we also must assign a unique number to each model type. ““Dude_friend”’ is 97, 
and “dude_enemy” is 98. Likewise, “jade_good(friendly)” is 99, and “‘jade_evil(enemy)” 
is 101. This model type identification number is made use of throughout NPSNET-IV.8. 1 


when a reference is made to a particular model or entity. Next, we assign the alive and dead 
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model number. The same number is used for all our models since we do not have a special 
dead model (we just manipulate the joints to make the alive model to look dead). After this, 
we assigned DIS-protocol specific identifications for the models. Assigned are a vehicle 
type, kind, and domain, a country code, category, designator, and model. Our friendly 
models are US while our enemy models are Soviets. Each of the models are assigned weap- 
ons by adding munitions lines under the model type definitions. 

Recall from Chapter II that entities in NPSNET-IV.8.1 are a part of a large class 
hierarchy. As shown in Figure 25, driven entities are children of the general class type 
“Vehicle”. Of interest to this research is the vehicle subclass “Person”. Dude, Jade, and 
Jack ML are subclasses of the “Person” class, from which they each derive their general 
velocity and physical attributes. Below the subclass “Person” level, each model has defined 


its own specific attributes. 





Figure 25: NPSNET-IV.8.1 Entity Class Hierarchy 


Finally, for all entities in use in NPSNET-IV.8.1, there are enumerations defined 
for each vehicle class type. The enumerations uniquely identify all of the class types of vari- 
ous entities in NPSNET-IV.8.1. With the addition of Dude and Jade, two more enumera- 


tions were necessary. Dude is assigned as 12 and Jade is assigned as 13. 
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3. Loading Models into NPSNET-IV.8.1 

The “Setup-Vtype” table routine in “netutil.cc” is responsible for loading all the 
dynamic models from “dynamic.dat”. Statements were added to handle letter cases “U” and 
“V” for the new human models. When starting NPSNET-IV.8. 1, all entity models are load- 
ed into the system database. Next, the user specifies which model to select, i.e., 
dude_enemy, dude_friend, jade_evil, jade_good, which prompts NPSNET-IV.8.1 to clone 
the geometry and structure of the selected model. At this input, the corresponding identify- 
ing tag for the model is either “U” or “V” which prompts “netutil.cc” to read the “dynam- 
ic.dat” model lines discussed above. For the case “U”, the cloned model data is passed to a 
table of vehicle types which keeps track of all the information of that particular model. This 
indicates that the alive model of this vehicle is our node structure. Also inherent to this 
structure is the creation of a rectangular bounding box for basic entity collision detection. 
A bounding box is created for each vehicle entity in NPSNET-IV by mathematically deter- 
mining the overall size range of that entity. Finally, supporting textures for the Dude 
models we supplied to the NPSNET-IV.8.1 list of textures. 

For the case of “V”, there is a slightly different procedure. As shown in figure 26, 

we create a pfSwitch called “which_human” and attach the Jack ML model as the left child 
and the Dude model as the right child. Since both models were previously loaded they are 


added to the pfSwitch with the pfAddChild function. Above the switch we create a pfGroup 
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called “jade”. This is required because NPSNET-IV.8.1 clones each model as it is instanti- 


ated and the clone process only clones a pfGroup. Finally we attach this switch to “jade”. 


group 


switch 


G_vehtype[85].model G_vehtype[97].model 
G_vehtype[86].model or G_vehtype[98].model 
if jade_good or jade_evil if dude_friend or dude_enemy 





Figure 26: Switch Structure of Jade 


4. Creating an Instance 

In “entity.cc”’, we added the capability to create an instance of our new entity types. 
Runtime selection clones a copy of the appropriate Dude model and attaches the top most 
node of DUDE_GEOM, rootGP, to a dynamic coordinate system node which is added to a 
group of other moving objects in NPSNET-IV. This function was added to the existing 
function “create_new_entity” for the cases Dude and Jade. Under each case, that particular 


class is instantiated. The following flow chart shows the basic structure of the new function. 






Case Jade f# Test Entity\ Case Dude 





Call JADECLASS Call DUDECLASS 
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Each of these calls its respective class DUDECLASS or JADECLASS constructor 
function. “Dude.cc” provides the constructor functions for creating and managing the Dude 
models. These models function in a stand alone mode in NPSNET-IV.8.1. A flow chart for 


their creation 1s as follows: 


PERSON_VEH 


Derive Entity Type 
Set Entity Status Upright Still 
Create Dude Entity 


Set icon to Alive 


Initialize model ranges 


Initialize Walking Data 


Get Channel 
Create Culling Point 


As shown above, Dude models are derived from the NPSNET-IV PERSON_VEH. 
The initial Dude model posture is set to standing which is handled by a flag setting it to 
upright and still. We then call the function “create_entity” which clones the DUDE_GEOM 


we created via our loader in “netutil.cc”. This cloned structure is the Dude model provided 








to the user. When a Dude model is created a cloned copy is made. Each clone is indepen- 
dent and has its own set of variables, joints, functions, etc. This cloned Dude model is 


attached to NPSNET-IV.8.1 by the use of a pfDCS called “hull” as shown in Figure 27. The 


user’s Dude model structure is the grandchild of hull. 


Dynamic Objects 


Jade or Dude 





Figure 27: Attachment of Dude Structure to Scene Graph 


NPSNET-IV.8.1 uses hull to move the Dude model to the correct coordinates in the 
virtual environment and to keep track of where the Dude model is located. Hull has a child 
of pfSwitch which has as its left child the Dude alive model, and as its right child an empty 
node. Because DUDECLASS has its own “create_entity” function which is called automat- 
ically, we find all of the DCS and Switch nodes of the cloned structure for each Dude model 
instantiation. In “dude.h” we created our own DCS and Switch nodes for each instantiation 
and we provide this to the respective node in the cloned structure by attaching the DCS 
nodes to the cloned structure and passing the main node the new model structure. These 
functions set the main_DCS (declared in dude.h) to the “hullDCS” as was shown in figure 
8 (Chapter III). At this point, we set initializers to display and articulate the Dude model. 
This is done in the definition “displaying_model = TRUE” and “dead = FALSE”. Then we 
set an inherited variable, “num_joints” to 9, since Dude_medium has 9 articulation points. 
Next, all the walking variables are initialized. Following this, we set the ranges for the three 


Dude models to 50, 100, and 250 yards. Note that these are 100 yards less than the distances 
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used with the Jade models supporting the Jack ML model. After this, we get the view chan- 


nel of NPSNET-IV.8.1 so as to perform entity culling. 


5. Manipulating the Object 
For each frame, NPSNET-IV.8.1 updates all of its entities by calling their respec- 
tive update functions: “move” for the local driven entity, and “moveDR’” for both the driven 


and the remote entities. “Move” provides the locomotion and collision detection functions 


for the driven entity. 


a. “move” 


“Move” takes its input from the user based upon what type of entity the user 
represents. At each NPSNET-IV.8. lupdate cycle, “move” provides PDU information to the 
network informing all remote sites of the user status. Each time through the main simula- 
tion loop, each active entity (both local and remote) is notified to perform a “moveDR” 
operation. Upon receiving this request, the entity dead reckons its new posture based upon 


its last posture, the amount of time since the last request, the last move/update and the dead 
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reckoning algorithm and data defined by the remote entity. The following flow chart shows 


the main points required for the driven entity manipulation: 


DUDECLASS move 





Get initial position 


Move 


(Move ] 
Live 


Get entity speed 


Get new position 


Get new posture 
Test for collision 


to vehicle posture 


Select dude_switch * 


Attach_pt * 
In general, the “move” function first finds the entity’s initial position. Next, 


“move” calculates the new position of the driven Dude entity based upon a time interval, 


velocity, and heading. After moving, the function tests for collisions. Following the moving 





functions, we next perform the custom culling functions. Taking the rest of “move” at each 


function marked with an “*” we step through the actions that occur next. 


b. “drawpt” 


At “drawpt’, we check to see if the Dude is in the viewing frustum. If the 


Dude model is not in the view frustum, we switch it “off” as shown by the following flow 


or 


Get Dude position 
Call dude_switch 


If the Dude model is being displayed and the “PtIsectFrust” test discussed 


chart: 






Switch mode 
off 





in Chapter IV shows the culling point is now outside of the view frustum, the Dude model 
is Culled out by the setting the pfSwitch to “PFSWITCH_OFF”. Likewise, if the model is 
not being displayed but now should be, the model is returned to the display by setting the 


pfSwitch to the current model in use. 


c. “dude_switch” 


At the function “dude_switch”, we find the distance from the viewer’s 
eyepoint to the Dude icon using the Euclidean distance formula and toggle the pfSwitches 


to display the right Dude LOD model. The following flow chart, called in the “move” func- 
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tion, shows the location of the distance calculations and LOD switching functions we use 


“dude_switch”’ 


Calculate distance to Dude 


to change Dude models. 


yes 





ho 










Distance < far range yes 


and > med far range ? 


no 






Distance < med far & 
> medium range ? 





a Dude medium_far 


no 
Dude medium 


In the calculation above, we test the distance from the eye point to the Dude 


icon to see if the icon has moved beyond the model rendering distance of 250 yards. If so, 


the icon is switched off. Next, we test the distance for the proper LOD model to display. 

















d. “dude_appear” 


At the function “dude_appear”’, we determine the user’s desired posture to 


display. The following flow chart shows the algorithms used: 


“dude_appear”’ 


Set head & eyes to 
correct position 


Get entity status 


_m we co 
_ ~~ 


yes 
Icon damaged Icon damaged ? | Icon — | 


no 
Speed = 0? no no 
no yes 


Set icon to standing Set icon to kneeling Set icon to prone 


peed <= 3.0? 


yes 


Set icon to running 
Set icon to walking 


From the above flow chart, it is possible to follow through the various 
maneuvers to call posture changing functions for the Dude models. At each call, the icon 
is manipulated using “pfDCSRot” and “pfDCSTrans” to achieve the desired posture. Note 


that in the above flow chart, speed ranges are defined for the Dude models. A velocity of 





0.0 indicates the icon is not moving. For velocities between 0.1 and 3.0, the icon is walking. 


Velocities between 3.1 and 10.0 are provided for rendering running Dude icons. 


e. “attach_pt” 


“Attach_pt” is a short function that places a culling point for a Dude icon 
in the same location as the moving entity. The following pseudocode shows the construc- 
tion of this function: 

DUDECLASS-attach_pt 
- Move the attached culling point to the Dude’s x, y, z position 


- Set the x, y, z, position of the point 


Ff. “moveDR” 


For the driven entity, the “move” routine allows updating and manipulation 
of the user’s icon. When other remote entities are present in NPSNET-IV.8.1, their icons 
are updated and manipulated by movement functions which dead reckon positions based 
upon previous information and elapsed time. “MoveDR” provides much of the same func- 


tions to the remote entities as “move” does to the locally driven entity. In addition, 
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“moveDR” determines whether a network packet update, an Entity State PDU, needs to be 
sent out. The following flow chart shows the vital “moveDR” functions: 


“moveDR” 


Set DR posture 


Put vehicle in 
correct location 















Call “drawpt” 


Call “dude_switch’”’ 





Set appearance 


Cali “dude_DR” 











yes 


Get entity speed 


DR data unchanged & 
PDU update time ? 


be aoa seamed 
Get entity status 


As shown above we call “drawpt” to determine if the remote Dude model 












should be rendered based upon the view frustum, “Dude_switch” is called to draw the 
correct Dude model, and “‘attach_pt” is called to attach the culling point to the remote Dude 
icon. “Dude_DR” determines the correct rendering posture and head orientation of the 
remote Dude icon. Also shown in the above pseudocode is the PDU update point. Incoming 
Entity State PDUs notify the local entity via “moveDR” of change in aremote entity’s state. 
Even if a remote entity is not moving, a “heartbeat” PDU message is sent at regular inter- 


vals. A default standard is that a PDU must be sent at least every five seconds. If an Entity 
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State PDU has not been received for every remote entity in two time periods, then the local 


object corresponding to the remote entity is removed. 


6. Special Features 

From the above flow chart, it is clear that multiple types of updates are requested 
based upon the current status of a Dude icon. These updates make it possible to control the 
icon and render it in the correct posture. For example if the icon is to be rendered as kneel- 
ing and not dead we call “dude_kneel’”’. If he is to be rendered in a dead posture, we call 
“dude_dead”’. For each Dude function update, a new head orientation is usually required to 
maintain realism. While it may seem trivial, head and eye orientation do not simply change 
with each posture change. As such, a separate function was created to accurately articulate 
the head and eye point. This function, called “rot_elev_head”’, rotates the head to match the 
user’s inputs. We handle looking left and right as well as up and down. The head can rotate 
through a maximum arc of +/-75 degrees yet the eyes are able to rotate through +/-90 
degrees. In this function, the head turns until it reached 75 degrees, then the view continues 
to shift simulating the eyes rotating in their sockets to 90 degrees. For pitch (up/down), the 
head moves through a maximum arc of +/-45 degrees while the eyes move through +/-90 
degrees. Additionally, if the Dude icon is prone he is only able to pitch his head forward 
(down) through 10 degrees. Also while prone, he can only look left and right through 45 
degrees. The maximum range for head and eye rotation are based upon extensive testing to 
achieve the most realistic movement. These ranges may be changed in compilation to 
reflect an individual user’s preference. The following flow chart shows the main points of 


the “rot_elev_head” function for the driven entity As for the remote, the head is rendered 
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based upon DIS PDU information. The remote model head manipulation routine does not 


calculate elevations or alignments. . 


Rotate/elevate head 


Reset head if new.) > 
or dead 


Set direction & 
elevation 














Check status of model 
(kneeling, prone, etc. 








et direction & 
elevation 


Move head 


e o 


to position 


C. JACK/DUDE (JADE) COMBINATION 


While the Dude portion of the software is designed to provide stand-alone human 
icon support using only Dude models, the Jade portion is designed to provide both Jack ML 
and Dude human icon support. For this purpose, we developed the class JADECLASS. 
JADECLASS was made a C++ friend of both DUDECLASS and the JACK_DI_VEH 
class. This allows Jade access to public as well as protected functions, variables, etc. of the 
two classes. The goal of this design is that the JADECLASS is the controlling logic for a 
switch that toggles between the two separate models, Jade and Dude, when full Jack ML 
icon support is required. This structure relies on the node structure created in netutil.cc as 


was discussed above. When using Jade, if the Jack ML icon moves to the view frustum 








range where it can switch to a Dude icon, the Jade software acts as the logic switch and 
passes the required information to render a Dude model. The converse is also true when 


Dude rendering ranges approach that for Jack ML. The following pseudocode shows the 


logic functions needed to switch models: 


Get movement data 


Call “moveDR”’ 


Upload model to render 


Download model to rende 
Download to Jack 


Create Jade variables 
at instantiation 


Create Jack and Dude 
variables 


The JADECLASS, similar to DUDECLASS, is derived from the PERSON_VEH. 
Basically, the JADECLASS is a child of PERSON_VEH that is inert when Jack ML and 


Dude are running in their respective stand-alone modes, but activated when running Jade, 








it becomes the sibling of both. The structure of the constructor is shown in the following 


flow chart: 


JADE Constructor 
Clone Jade node 


Set mil. force flag 
Clone switch node 


Find Jade 
cloned nodes 
Create Dude & 

Jack 


Apply range offset 


Initialize Jade 


Set # of articu- 
lation points 


Here we call the constructor function “create_entity” which clones the structure 
built in “netutil.cc”. Next, we set up initializers for the Jade class and then name the nodes 
of the clone to allow multiple Jades icons independent movement. If this were not done, all 
Jade icons created would have identical motions based upon the first master Jade icon. 
After naming, we instantiate a Dude and a Jack ML model by making calls to a special 
constructor in each respective class. The special constructors are shortened versions of the 


respective stand-alone constructors. The new constructors fill in the unique model data for 
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its Dude/Jack model and disregard stand-alone NPSNET-IV.8.1 model tie-ins. Also we 
added a variable to Dude called “Jack_offset” which handles the transition distances for the 
LOD in the presence/absence of a Jack ML model. When running in stand-alone mode 
Dude has a Jack offset of 0.0 meters so the LOD switches are set at 50, 100, and 250. When 
Jade is activated it sets the Jack offset to 100.0 yards. This means that Jack is used for 100 
yards, then Dude is used with LOD switching occurring at 150, 200, and switching off at 
350. Completing the JADECLASS is the destructor. It is a short function best summarized 
in the following pseudocode: 

JADECLASS-~JADECLASS 

- Delete Jack 

- Delete Dude 

Here we simply deallocate all memory we had requested by instantiating the two 


classes. 


1, Jade pfSwitch “whichSwitch”’ 
The Jade pfSwitch “whichSwitch” is a controlling factor to displaying and articu- 
lating the rendered entity. This function, manipulated in the function “switchHuman,” 


ensures there is proper data transferred to the motion algorithms of the selected icon. It 
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simply acts as a controlling switch through which the correct model is chosen for rendering; 


The following pseudocode describes some of “‘whichSwitch’s” functions: 


Calculate distance to Jade 







no yes 


Set icon to Dude 


Set icon to Jack 


Set Jack 
speed 






Distance > Jade 
range +20? 







Send PDU 


Snap transition 
off 






Update Jack 





Has icon 
changed ? 


Change “whichSwitch” 


Download data 
to icon ne 


For this switch, we have a local variable set to the Jack ML icon when this 





function is called. We use the Euclidean distance formula determine how far away the Jade 
model is from the viewer's eyepoint. If the calculated distance is greater than the Jade range 


of 100.0 yards, the local variable is set to Dude. Also here, we check to see if we are near 
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the same switching range point so as to get Jack ML updated to the same posture as Dude 
to make transitions look smoother. Here too, we turn off Jack's posture transition functions 
and simply snap Dude to position. Next we see if a model switch occurred. If it did, we give 
the newly selected model all of the data it needs to function properly by performing a down- 
load of data. If we have returned to a Jack model, we move the switch to Jack and restore 


Jack's intermediate posture transition algorithms. 


2. Updating the Jade Model Status 


After switching, we must next update the icon status. The following flow chart 


shows how this is performed: 









Set Jack status Set Dude status 


Get new status 


Here Jade calls the same function to update icon status in the appropriate model 
being displayed. We also set the velocity to 0.0 if Jade is damaged or destroyed. From here, 
we must receive new Entity State PDUs for networking the Jade models. This performed 


as in the following manner: 


Entity State update 







Get Jack PDU Get Dude PDU 


Here again Jade calls the same function to update icon status in the appropriate 





model being displayed. After having obtained entity updates, Jade is now ready to move or 
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dead reckon the proper model. This is shown in the following flow chart for the Jade 


“move” function: 


Jade “‘move’”’ 


Jac Dude 


Call Jack “move” Call Dude “move 


é< 2 
et data from Dude 










Get data from Jack 









Upload to Jade 


The above flow chart was designed with code reuse in mind. Simply, here we again 
call “which_human”’ to get the right model. Based upon that call, we call the appropriate 
class move. Finally, we upload all the necessary data from the desired model into Jade. 


From this we are able to move and fully support both Jack ML and Dude. 








3.  Jade’s MoveDR | 

The “moveDR” function for Jade is similar in design to the above “move” function. 
The main goal again is code reuse, and like Dude, it is based upon elapsed time and Entity 
State PDUs. The design is apparent in the following flow chart for Jade “moveDR”: 


Jade “moveDR”’ 


Jack Dude 


Call Jack ““move’”’ Call Dude “move” 
Get data from Jack Get data from Dude 


























Is icon the 
driven icon ? 


YES _ (Send PDU 





Exceeded DR 
time limit ? 


send PDU 
pdate icon status 


As one can see, this function is quiet similar to the Dude “moveDR” described in 





detail above. Making use of existing code, if we are not the driven vehicle, we call the 
appropriate “moveDR” of the model shown. Here too, one finds the functions to send Enti- 


ty State PDUs to the network. 
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4. JADE Data Uploading and Downloading 

The two critical functions below provide the smooth transfer of pertinent data 
between Jack ML and Dude models. The “upload” function provides the displayed model 
status to Jade. Similarly, the “download” function passes the required data from Jade to the 


next model. The following pseudocode clarifies the operations of these two functions: 


JADECLASS-upload 





- Upload pertinent data to Jade from correct model 
- If model displayed 1s Dude 
- Get Dude’s heading, posture, and speed 
- Get Dude status 
- Send Dude’s status to Jack 
- Pass Dude head movements 
- Else 
- Get Jack’s heading, posture, and speed 
- Pass Jack status 
- Pass Jack head movements 
Here we check to see what model is currently displayed, and get all the pertinent 
data from it into Jade. This function is the downloading function, described by the follow- 
ing pseudocode: 
JADECLASS-download 
- Download pertinent data from Jade to correct model 
- If displayed model is Dude 
- Get Dude’s heading, posture, and speed 
- Get Dude status 
- Send Dude’s status to Jack 
- Pass Dude head movements 
- Else 


- Get Jack’s heading, posture, and speed 
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- Get Jack’s status 
- Send Jack’s status to Dude 


- Pass Jack’s head movements 


D. SUMMARY 


While the addition of level of detail icons to an existing model may seem simple, 
their proper integration and manipulation, especially if they are articulated, is not an easy 
task. Extensive software additions were required to effectively add three supporting LOD 
icons and their associated motion algorithms to NPSNET-IV.8.1 for Jack ML support. The 
Same extensive modifications were required to provide stand-alone Dude support for the 
system. Using software engineering techniques, the modifications take advantage of code 
reuse. Still, new functions were created that properly switch models for displaying, and 
transfer articulation information between the articulated icons. These new software modi- 
fications now provide NPSNET-IV.8.1 with full Jack ML LOD support, as well as fully 


functional, stand-alone Dude capabilities. 
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VI. CONCLUSIONS 


A. OVERVIEW 


The inclusion of level of detail models composed of fewer polygons than an exist- 
ing high level model, together with view volume culling and entity range management 
ensure NPSNET-IV.8.1 can satisfy requirements of displaying 150 DI icons and still main- 
tain a frame rate of 10-15 frames per second. NPSNET-IV.8.1 now has the capability of 
supporting the Jack ML model as well as providing stand-alone Dude model support. The 
inclusion of the new model types (Jade and Dude) has significantly enhanced NPSNET- 


IV.8.1 human interaction capabilities. 


B. JACK BEFORE DUDE 


As a baseline, an initial run of NPSNET-IV.8.1 using only the Jack ML icon was 
made. As shown in Table 6, less than 15 Jack ML icons are required to drop the frame rate 
below 10.0 frames per second. The large number of polygons used to create the Jack ML 
model, coupled with the computational expense of articulations, make it nearly impossible 


to maintain a real-time virtual environment composed of Jack ML icons alone. 


Icon Displayed Frames per second Frames per second - 
unarticulated 


eR a a I DPE | ST 


| 


Table 6: Jack ML Data 












i 


C. RESULTS OF DUDE 
The following results were obtained for 18 Dude models on Elvis using flags -n stat- 
ic, and -n animations on the Fort Benning terrain database. This data was collected with 150 


Dude icons in the virtual environment. When no models were displayed, our frame rates 
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fluctuated between 25 and 30 frames per second. Data was also collected with static objects 


present, but no significant change in frame rate was realized. 


12 medium, 6 med far, 24 far 
6 medium, 6 medium far 


Table 7: 150 Dude Entities 










D. RESULTS OF JADE 


As a final test, Jade was used to support Jack ML again on the Fort Benning data- 
base. This data was collected with not more than six of the 18 or 36 icons in the view frus- 
tum. Of note, when all 18 icons were being rendered as Jack, the frame rates dropped by 
nearly half of the below values. This result is consistent with a stand-alone Jack ML exer- 
cise with all 18 Jack icons in the view frustum. A similar result occurred with 36 icons in 
the view frustum. Frame rates dropped to 1-2 frames per second, consistent with the Jack 


ML stand-alone version of 50 icons. 


18 medium far 


Table 8: 18 & 36 Jade Models 
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E. RESULTS OF ENTITY CULLING 


Entity culling is extremely effective and important to preserving frame rates. From 
the above model results, it is clear that by removing non-visible entities, one can preserve 
frame rates by discarding objects outside of the view frustum. Equally effective to ensure 
frame rate preservation, range management also reduced the number of managed, articulat- 
ed icons in the virtual environment. While testing culling results with 150 entities does 
show significant frame rate preservation, entity culling will become extremely important 
when NPSNET-IV.8.1 users begin to exceed the normal limits of the graphics machine in 
large-scale exercises, 1.e., exercises of 500 or more users. Nonetheless, view volume cull- 


ing and range management proved highly effective in maintaining real-time performance 


in NPSNET-IV.8.1 


F. CONCLUSIONS 


From the above results, it 1s clear that the basic goal of this thesis was met. We 
succeeded in supporting 150 DI icons in NPSNET-IV.8.1. Unfortunately, it was not possi- 
ble to significantly increase the number of high resolution DI icons through our efforts of 
LOD modeling and entity culling. From the above data, we can conclude that NPSNET- 
IV.8.1 will render and manage at least 150 Jade DI icons, with not more than 5-6 being 
displayed and articulated as the Jack ML model. The upper bound on frame rates is not the 
number of Jade icons present in the virtual environment since NPSNET-IV.8.1 easily 
supports this number when they are not all being rendered or articulated. Clearly, range 
management is useful to conserve frame rates by not managing entities in the distance. 
NPSNET-IV.8.1’s frame rates suffer when the entities are being rendered and articulated 


in the view frustum. 


G. FUTURE WORK 


While the Jade/Dude software is effective in enhancing human interaction in 
NPSNET-IV.8.1, itis clear that this increase in interaction leads the way for more improve- 


ment in human interaction. The following is a partial list of future improvements needed to 
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further enhance the Jade/Dude software. Some of these improvements will become trele- 
vant with future increases in human icon interaction and NPSNET-IV input device. In the 
mean time, their contributions would do much to further enhance the new capabilities of 


NPSNET-IV.8.1. 


1. Realistic Walking Algorithms 

The current Jade/Dude walking algorithms are adequate for short term support of 
the Jack ML icon, however, to more closely model actual human motion, an improved 
walking algorithm is required for the Jade/Dude program. Smoother articulations and a 


closer match of speed to icon movement are required to complete the Jade/Dude software. 


2. Special Activity Algorithms 

Currently, activities such as climbing steps, entering building through windows, 
parachuting, driving, and basic human interaction other than that described in this thesis is 
not supported for either Jack ML, Jade, or Dude. Special scripted or interactive animations 
are required to fully depict these activities. The addition of special animations will tremen- 
dously increase the realism of the human interaction portion of NPSNET-IV.8.1. 

Additionally, when the Dude model is damaged or destroyed, the icon is replaced 
with smoke and a crater, further efforts are required to override this default death script and 


create a special one for the human Dude ground vehicles. 


3. Improved Jade Switching Algorithm 

An improved switching algorithm is needed in Jade so that when switching 
between the models (Jack & Dude) the condition of fluttering is eliminated. This condition 
occurs when the viewing distance falls within a narrow range where icon movement causes 
it to fluctuate between 99, 100, and 101meters. A new switching algorithm is required that 
does not continue switching but picks one model and continues rendering it until the 


distance moves beyond the indecisive transition point. 
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[BADLER] 


[PTBARH] 


[TAFUNK] 


[JPGRANTJ 


[JPGRAN2] 


[IDA] 


[TRIS] 


[HLMOHN] 
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